Stone theorem for norm-continuous unitary one-parameter groups - #1510

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.

Many thanks for this PR.
Just some quick comments which I think need addressing before merging or getting into the details:

1. In Physlib we use lemma instead of theorem.
2. Might be worth running min_import at the bottom of each file to reduce the number of imports.
3. Worth checking for definitions which are simple rephrasing of things in mathlib e.g. oneParameterNormedRing.
4. Worth checking how much of this one-parameter subgroup stuff can be taken from Mathlib, rather then needing to include it here.

awaiting-author

The final result here is really great work. Though, I do have a couple of concerns that still make it a bit hard to review in its current form:

1. Connection to existing quantum mechanics API: This doesn't currently link up with the self-adjoint operators that already exist in the codebase. I'd expect this result to build on/connect to those. Could you take a look at how they're structured and see if we can tie this in? This may also mean moving the file you added to the right place.

2. Framing as physics vs. math: Right now this reads as an API around mathematics rather than physics. I think there's a lot of useful physics we could surface here if we frame it a bit differently — could we look at adjusting the naming/structure/organization to make the physical meaning clearer?

Thanks for your patience. I am still getting familiar with Lean and with Physlib’s file and folder structure.

I have reworked Stone.lean so the main result is now basis-independent and phrased directly in terms of physics: continuous unitary time evolution corresponds to a unique bounded self-adjoint Hamiltonian through

$$U(t)=\exp(-itH/\hbar).$$

It now works with bounded operators on a Hilbert space and is connected directly to FiniteTarget.timeEvolution. The general unbounded version would require spectral theory and strong operator continuity that are not yet available in Physlib.

I have left the two underlying one-parameter subgroup files under Mathematics. I’m happy to hear any other ideas for how this result could be integrated more naturally into Physlib.

-awaiting-author

awaiting-author

Thanks for all these comments. I have reworked the PR to incorporate the feedback:

• the general result now uses Mathlib’s AddChar;
• I removed the redundant matrix file and the definitions duplicating existing Mathlib machinery;
• the physics result now lives in UnitaryTimeEvolution.lean;
• UnitaryTimeEvolution directly exposes the group laws U(0) = 1, U(s+t) = U(s)U(t), and U(-t) = U(t)⁻¹;
• the correspondence is phrased in terms of bounded self-adjoint Hamiltonians and integrated with FiniteTarget.timeEvolution.

Thanks again for the detailed guidance.

-awaiting-author

Thanks for all the detailed comments. I made a final structural pass through the PR and reworked the result around the more general object.

The central definition is now UnitaryOneParameterGroup, under Mathematics/OneParameterSubgroups. It stores an AddChar into the Mathlib unitary subgroup, while its coercion returns the underlying continuous linear operator, so expressions read simply as U t without repeated casts. I kept unitarity as the intrinsic condition here, since the operators U(t) are generally not self-adjoint.

The long existsUnique_hamiltonian proof has been removed. The API now defines the canonical self-adjoint generator, proves U(t) = exp(-itA), proves uniqueness, constructs a group from any bounded self-adjoint operator, and packages the correspondence as stoneEquiv.

Hamiltonians are now treated as the time-translation specialization rather than as part of the general theorem. FiniteTarget.unitaryTimeEvolution is generated by H/ℏ; this is exposed directly by unitaryTimeEvolution_generator, and the existing formula U(t) = exp(-itH/ℏ) follows from the general result.

I also incorporated the proof-structure suggestions in OneParameterSubgroups/Basic: the integral calculation is a calc, translation of the interval integral is a separate lemma, and the generator and uniqueness arguments have fewer intermediate facts. The redundant matrix specialization remains removed.

This seems to give a cleaner separation between the reusable Stone correspondence and its physical interpretation as time evolution. I am happy to adjust the placement or naming if you would prefer a different organization.

-awaiting-author

Thanks for your suggestions!
I think I have incorporated them as much as possible.
"U.toAddChar" Im still using in one or two places. I wasn't able to get completely rid of them.
-awaiting-author